@CuiYifeng

Currently evaluating the use of a more localized approach using #pragma clang fp reciprocal(off) to minimize the impact on performance. Do not merge for now.

There are a few options regarding #pragma clang fp reciprocal(off) (https://clang.llvm.org/docs/LanguageExtensions.html#extensions-to-specify-floating-point-flags) with the least invasive being adding it only to the BinaryDivTrueKernel.cpp file. However, I'm not sure whether it's worth it to sacrifice some performance for accuracy in this oddly specific use case (calling div first and than trunc instead of div_trunc) for which we have no known business need outside the failing UT. Both the div and div_trunc results are within needed norms. It might be better to modify the UT. What is your opinion on that @EikanWang?

There are a few options regarding #pragma clang fp reciprocal(off) (https://clang.llvm.org/docs/LanguageExtensions.html#extensions-to-specify-floating-point-flags) with the least invasive being adding it only to the BinaryDivTrueKernel.cpp file. However, I'm not sure whether it's worth it to sacrifice some performance for accuracy in this oddly specific use case (calling div first and than trunc instead of div_trunc) for which we have no known business need outside the failing UT. Both the div and div_trunc results are within needed norms. It might be better to modify the UT. What is your opinion on that @EikanWang?

@SanityRemnants , Although the performance is the king, I'd prefer to keep a high bar of maintenance when we have no concrete performance impact.

• @SanityRemnants since it is close to the PyTorch 2.10 branch cut date, I'd like to defer this PR landing.
• @weishi-deng , @chuanqi129 , could you help collect the performance data w/ this PR? My expectation is that this PR only impacts a few micro-benchmarks and there should be no impact on E2E models. Priority-wise, the collections is lower than PT 2.10.

There are a few options regarding #pragma clang fp reciprocal(off) (https://clang.llvm.org/docs/LanguageExtensions.html#extensions-to-specify-floating-point-flags) with the least invasive being adding it only to the BinaryDivTrueKernel.cpp file. However, I'm not sure whether it's worth it to sacrifice some performance for accuracy in this oddly specific use case (calling div first and than trunc instead of div_trunc) for which we have no known business need outside the failing UT. Both the div and div_trunc results are within needed norms. It might be better to modify the UT. What is your opinion on that @EikanWang?

@SanityRemnants , Although the performance is the king, I'd prefer to keep a high bar of maintenance when we have no concrete performance impact.

• @SanityRemnants since it is close to the PyTorch 2.10 branch cut date, I'd like to defer this PR landing.
• @weishi-deng , @chuanqi129 , could you help collect the performance data w/ this PR? My expectation is that this PR only impacts a few micro-benchmarks and there should be no impact on E2E models. Priority-wise, the collections is lower than PT 2.10.

There is no such issue on CUDA.
IPEX has added some similar parameters to fix the accuracy issue.
Looks like they are not upstream to Pytorch.

This parameter is neither in IPEX or in PyTorch.
It only impact the OPs including divide().

We are waiting for this PR to fix related issue.
Please speed up the review!

Thank you!